Subject: Re: TCP Connection Management ( Peter's 8/18 reply)

From: [email-masked] (Anand Subramaniam)
Date: Wed, 15 Sep 93 14:28:58 PDT

Peter,

Thanks for your comments. I could not get back soon as I was at the InterOp.
I also spent some time thinking more about the proposals and also discussed
some of them  with others. I shall try to address all your questions in this note.

First the MODELS,

1.    proposes 1 tcp connection per DL circuit.

2.    Uses the existing 2 TCP connections which multiplexes all the
    DL circuits but uses the "unused" TCP channels to transmit and
    receive proposed IPM messages.

Refer to my earlier note for more detailed description of the above.

Now the issues,
==============
Peter writes,
------------

> The argument that this will save us from having to invent a pacing
> scheme (and other arguments FOR the proposal) imply that this will be
> the only approach used.  I assume the connect sequences would not
> prevent circuit multiplexing, just that there would be no architected
> DLSw fairness/flow control mechanism for multiplexed circuits.  This
> punishes vendors whose implementation constraints make supporting
> many TCP connections impractical.

I discussed the models with many others(some transport experts) here. Many
seem to agree that that model 1 is relatively simple and the DLSw would take
advantage of the flow control already built in most connection-oriented
transport protocols and thus prevent us from re-inventing the wheel and
introduce a lot of redundancy. 

I strongly agree that one thing that would make this IMPRACTICAL is the
LIMITATIONS imposed on the number of transport connections supported in a
box in some implementations. Many felt that if at all Model 1 does not get
accepted, it would be mainly because of this.

> This approach does not remove the requirement for an implementation
> to deal with the circuit fairness issue.  A receiving box still has
> finite resources.  If some memory is being used up by a "bad"
> circuit, it is unavailable to other circuits, whether there is one
> circuit per TC or many, no matter if the space is held by TCP or
> some other component.  All the proposal does is say that only TCP
> mechanisms are available to reflect conditions to one's partner.
> This ties a DLSw implementation more to TCP, making it harder to
> migrate to other platforms.  I agree with the goal of keeping DLSw
> simple so I can see the advantage of standard mechanisms, but I
> think the negatives outweigh that advantage.

Model 1 does remove the requirement for an implementation to deal with the
DL circuit fairness issue.  A receiving box sure does have finite resources
but  a reliable transport would solve it by having both windowing and flow 
control. The circuit fairness is entirely a local implementation issue. It
depends upon how the circuits are scheduler by the scheduler .... 

At this point I would like to pose a question to the group. Do we want a
simple DLSw or do we want a more complex DLSw which would resemble a reliable
transport? If we have a simple DLSw, it would be required that the transport
be reliable or if the DLSw itself is quite reliable, we can get away with a
simple transport. Both are achievable.

> I do not agree with your statement "If we need to support a LOT of
> DL connections, then we should not really worry about memory".  I
> always worry about memory.  SDLC has a low circuit-to-physical-
> router-port ratio, but in the LAN environment this can be a very
> large number, meaning thousands of circuits in a router.  Not
> everyone has a space-optimized TCP implementation.  Your argument
> that pacing will require more buffer space than the "circuit per TC"
> proposal does not make sense to me.  The buffer space needed for DLSw
> should be independent of whether the buffering is assigned to TCP
> or some other component.

This is a complex topic and let me try to make it look simple. If we were to
use model 1 then to total send window could be the sum of the DL send window
+ transport send window. In fact we could end up buffering one buffer in the
DL connection and rely on the transport send window. 

Let's take the case of using proposed IPMs. Currently there is no way to
dynamically reduce the window i,e once the receiver has advertised a window,
he can either close the window completely or has to receive all the messages up
to the advertised receive window. Only after that he can reduce the window.
This means that the DL cicuit must either pre-allocate all the buffers or 
must have a smart statistical scheme. 

To support reduction of window we have to end up introducing sequence numbers
and retransmission timers. A combination of sequence numbers and available
window would insicate whether the window has opened or reduced and
retransmission timers would ensure that any dropped messages could be
retransmitted.

> On connection establishment, my concern was not so much the added
> latency (which is small IF all goes well) but the added complexity.
> Bringing up a circuit can be tricky by itself without added TCP
> connection bring up and take down (e.g., bring up right after take
> down, etc.) considerations.

Model 1 makes it more simpler because the circuit is tied in with transport.
If TC dies then the DL circuit also goes with it. 

> If we were to allow muliplexing on some TCs, I still don't understand
> how you are proposing to determine traffic characteristics of a
> circuit.  SKR's 8/12 proposal of dynamically shifting a circuit from
> one TC to another made sense to me as a possible approach, but your
> references to OSI transport classes didn't explain how one knew to pick
> the appropriate class.

With model 1 we would not be using any multiplexing. I would very much like to 
hear more about SKR's proposal of dynamically shifting a circuit from one TC to
another.

Scott Writes:
==============

> Our boxes at Cayman are on the small side thus we live under significant
> resource limitations. This includes the number of TCP connections we can
> support

I agree. If we find out that many have this limitation, then we may have to
proceed on with model 2.

Clarifications on Model 2
=========================

Model 2 extends the existing schemes(proposed by Peter)  to ensure that IPMs 
are delivered properly and do not get flow controlled  along with other data as this would defeat the purpose of pacing. To achieve this we definitely need 
2 transport connections. 

Proposal Summary
=================

        Model    1                           Model 2
        ==========                            ========

        1 TC per 1 DL circuit        1 TC per many DL circuits
                                     Extension: Use the unused
                                     channels in the TCP
                                     connection pair to send and
                                     receive IPMs.

Advantages::
============
    1. Complete transport bandwidth       1. This fits in well with
    for the DL circuit.                    existing implementations.
    2. We won't be needing a new flow     2. Ensure that IPMs reach
    control scheme which makes DLSw         faster.
    simple.                               3. Fewer TCP resources used.
    3. The disconnection of the TC will      This would make it more     
    affect only the associated DL circuit    PRACTICAL as some router
    and not others.                          boxes have pre-configured
    4. We don't need a new scheduling        limits on number of TCP
    mechanism to schedule the DL circuits    connections.
    when sharing the transport transmit
    bandwidth.

DISADVANTAGES
=============
    1. More TCP resources would be used.      1. Redundant flow control.
    This would make it difficult for some     2. Need to implement a
    vendors whose boxes are small and           transport bandwidth fair
    have pre-configured limits on number        share algorithm.
    of transport connections they can         3. Dependency of all DL
    support.                                    circuits on a single TC. If
    2. Incompatibility with existing imple-    the TC all the circuits die.
    mentations.

Conclusion
==========

I hope I have attempted to answer your questions. Now that all of us are 
fairly clear regarding the issues involved , I encourage more participation
by other vendors which would help in focusing our efforts in a particular
direction. 

Regards,

andy

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UUCP:  {ames,apple,sun,mtxinu}!excelan!andy         (Anand Subramaniam) |
| INTERNET:  [email-masked]                          Ph : (408)-473-8413 |
| " Now and then I go off in to my own little world; But they know me     |
|   there"                                                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+